COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	Arthur Keller, Part 1
C00014 00003	New section
C00019 ENDMK
C⊗;
Arthur Keller, Part 1

This section discribes the nessesary semantics of choosing a translator
that converts from view updates into database updates.
In previous chapters we have generated an exhaustive list of all 
possible view update translations that satisfy our criteria.
The translator uses a view update translation for every view
update supplied.
From the list of all possible view update translations we could 
generate the list of all possible view update translators, but we have
no interest in doing so.
This is because most of these translators involve combonations of
translations that are not semantically meaningful.
?? we will provide an algorithm chooses?? a view update translator by
engaging in a dialog with a database administrator at view definition time.
Such a view update translator is chosen as the user specifies a view update.
The translator will automatically generate a translation to a database update
without further decision making or intervention from the user.
The view update translation will then be performed unless a constraint is
violated, in which case the view update will be rejected.
At view definiton time the database administrator will define the view
in an ordinary sequel view definition.
View definition facility will then convert this view definition into
a query decribed in select-project-joined normal form.
We do this by taking advantage of the information generated at database
definition time.
In particular we take the key of each relation mentioned in the view, and make
sure it is included in the attributes projected into the view.
Using the knowledge of keys for each relation, we can determine the 
direction of each join.
Using a queriograph where each relation is represented by a node, and each
join is represented by a directed edge, we make sure that the graph is a 
rooted tree.
If it is, this view is updatable and we may proceed to obtaining the nessesary
semantics.

Recall that our algorithm for handling select-project-joined views translates
view updates into a series of view updates on select-project views.
Consequently the choice of a view update translator for select-project-joined
views requires the choice of a translator for each select-project view.
??verse the tree coresponding to the view definition in tree-order starting
at the roots.
The root is handled specially because deletion occurs only at the roots.
There is no selection on the roots ?? must translate the deletion of a
view tuple into deletion of the corresponding root database tuple.
However, if there is a selection on the root relation, and the selecting
attributes of the root relation are not completely contained in the key
of the root relation, then deletion of a view tuple my be translated into
replacement of a tuple in the root relation of the database.
Thus our first question to the database administrator is whether deletions
of view tuples are to be translated into deletions of database tuples,
or into replacements of database tuples.
If the answer is that a deletion is to be translated as a deletion, then we
proceed onto the question of insertion of view tuples.
On the other hand, if the answer is that deletion of view tuples are to be 
translated into replacement of database tuples, then we must proceed
to determining the nature of the replacement.
We ask the database administrator to choose a ?? atribute of the root 
relation that is not part of the key.
We then consider the excluding values for the attribute chosen.
If there is only one excluding value, a view tuple deletion will be translated
into replacing the root database tuple, by changing the chosen attribute
to its single excluding value.
If there are multiple excluding values for the chosen attribute, we 
ask the database administrator to select one of these. 
This particular value will be used as if there were only one excluding 
value as we have explained.

The next consideration is insertion of view tuples.
We will look at the root relation and determine whether there is a selection on this relationk
this relation.
If there is we give the database administrator three options.
The first option is to allow insertions into the database but not to change 
existing database tuples.
The second option is to change existing database tuples but not to allow
insertions into the database.
The third option is to allow both insertions into the database and replacements
of existing database tuples.
In the event that there is a projection on the root relation, and we have 
allowed the user to insert new database tuples, we must determine the values
of attributes not appearing in the view.
For each attribute not appearing in the view in this relation, if there is a 
single selecting value we use that selecting value, otherwise we ask the
database administrator to choose one of the selecting values.
This will mean choosing a value from anywhere in the domain for non-selecting
attributes.
For relations other than the root relation we give the database administrator
four options.
The first option is to not allow the update if the database tuple does
not exist in the desired form.
This coresponds to only allowing new employees to be inserted into existing
departments with the information about the departments unchanged.
The second option is to allow an insertion into this relation, but not
a replacement of a conflicting tuple in this relation.
The third option is to allow a replacement in this relation, but not an
insertion into this relation.
The fourth option is to allow both insertions and replacements into 
this relation.
If the relation has attributes that do not appear in the view, and we allow
insertions into the relation, we must specify where the other attributes 
get their new values.
?? is identicle to that described for the root relation.

We now consider replacement of view tuples.
If the key of the view tuple changes, that will involve a replacement of the 
root database tuple changing its key.
Recall that there are four algorithms which do this.
We will choose a replacement algorithm that coresponds to the deletion
and insertion algorithms we have chosen for the root relation.
If the key of the view tuple does not change, there is only one
replacement algorithm we need consider on the root relation or other
relations.
We give the database administrator the option of choosing
the same restrictions for this relation on the view replacement requests
as chosen for view insertion requests.
This will permit the replacement translator coresponding to the
insertion translator to be used.
Alternatively the database administrator may choose one of the four options
for insertion requests for replacement requests.
This may be further devided into four options for state R and four options
for state I.
Recall that states R and I are used in the algorithm for translating
select-project joined view updates, into select-project view updates on
individual relations.
New section
A view update translation is valid if the view tuple is changed exactly 
as requested.
In particular this means that if a view tuple is deleted, that tuple
no longer appears in the view.
If a view tuple is inserted, that tuple appears in the view exactly as requested.
And if a view tuple is replaced, the replaced view tuple no longer appears in
the view, and the replacement view tuple appears in the view in its exact form.
For select-project views this can be accomplished without any view side effects.
That is, no view tuple will be changed other than the one that the user has
requested to be changed.
For select-project-joined views this is not always possible.
If a replacement is made to a relation other than the root relation of the 
view, there is a potential for some view tuple to be affected other
than the one the user has requested to be changed.
For example, suppose we have an employee in a particular department with a
particular manager, and we require that an employee have a unique department and
and a department have a unique manager.
If we change the manager for a particular employee, we retain the employee in
same department.
If we are to accept this update, we have no choice but to change the manager 
for that department.
We will require that every other employee in that department have the new 
manager.
Given the view updates, we can determine which view tuples are affected without
considering the translation of this view update into database updates,
assuming of course that the view update is accepted.
First, view deletions cannot affect any view tuple other than the view 
tuple deleted.
For view insertions and replacements we look at every relation represented in
the view, and consider whether the replacement or inserted view tuple has a
conflict with an existing database tuple.
That is, in our select-project-joined view update algorithm whether we
will translate this into a replacement on the select-project view.
In this case only, any other view tuple that shares this select-project 
view tuple undergoes a change to match the new select-project view tuple
determined by the new select-project-joined view tuple.
If we do not wish this to happen we may reject the select-project-joined
view update request.

Recall the communitive diagram for translating view updates into database 
updates.
This diagram will actually commute if we have a view update for select 
and project views.
For select-project-joined views, if we allow replacements on relations other
than the root relation, instead of exactly performing the user's request;
we actually take the user's request plus a series of updates to other
view tuples, in order to maintain consistancy in the functional dependancies.
The diagram will commute with this augmented view update.
Note that the augmented view update discribes the result of performing
the requested view updates on the database when translated to a database 
update sequence.
Thus the view update translator need not consider the augmented view update,
but need only consider the original view update request.